home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1993 / Internet Info CD-ROM (Walnut Creek) (1993).iso / inet / internet-drafts / draft-ietf-atm-classic-ip-02.txt < prev    next >
Text File  |  1993-08-23  |  32KB  |  785 lines
  1.  
  2.  
  3.  
  4. Network Working Group                                       Mark Laubach
  5. Request for Comments: DRAFT                 Hewlett-Packard Laboratories
  6. Expires February 20, 1994                                August 20, 1993
  7.  
  8.  
  9.  
  10.  
  11.  
  12.  
  13.                      Classical IP and ARP over ATM
  14.  
  15.  
  16. Status of this Memo
  17.  
  18.    This memo is an internet draft. Internet Drafts are working documents
  19.    of the Internet Engineering Task Force (IETF), its Areas, and its
  20.    Working Groups. Note that other groups may also distribute working
  21.    documents as Internet Drafts.
  22.  
  23.    Internet Drafts are draft documents valid for a maximum of six
  24.    months.  Internet Drafts may be updated, replaced, or obsoleted by
  25.    other documents at any time. It is not appropriate to use Internet
  26.    Drafts as reference material or to cite them other than as a "working
  27.    draft" or "work in progress".  Please check the lid-abstracts.txt
  28.    listing contained in the internet-drafts shadow directories on
  29.    nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, ftp.nisc.src.com, or
  30.    munnari.oz.au to learn the current status of any Internet Draft.
  31.  
  32. 1.  Abstract
  33.  
  34.    This memo describes an initial application of classical IP and ARP in
  35.    an Asynchronous Transfer Mode (ATM) network environment configured as
  36.    a Logical IP Subnetwork (LIS) as described below and in [1]. This
  37.    document does not preclude the subsequent development of ATM
  38.    technology into areas other than an LIS; specifically, as single ATM
  39.    networks grow to replace many ethernet local LAN segments and as
  40.    these networks become globally connected, the application of IP and
  41.    ARP will be treated differently. This memo considers only the
  42.    application of ATM a as a direct replacement for the "wires" and
  43.    local LAN segments connecting IP end-stations and routers. Issues
  44.    raised by MAC level bridging are beyond the scope of this paper.
  45.  
  46. 3.  Acknowledgment
  47.  
  48.    This memo could not have come into being without the critical review
  49.    from Jim Forster of Cisco Systems, Drew Perkins of FORE Systems, and
  50.    Bryan Lyles, Steve Deering, and Berry Kercheval of XEROX PARC.  The
  51.    concepts and models presented in [1], written by Dave Piscitello and
  52.  
  53.  
  54.  
  55. Laubach                                                         [Page 1]
  56.  
  57. DRAFT                Classical IP and ARP over ATM           August 1993
  58.  
  59.  
  60.    Joseph Lawrence, laid the structural groundwork for this work. This
  61.    document could have not been completed without the expertise of the
  62.    IP over ATM Working Group of the IETF and the ad hoc PVC committee at
  63.    the Amsterdam meeting.
  64.  
  65. 4. Conventions
  66.  
  67.    The following language conventions are used in the items of
  68.    specification in this document:
  69.  
  70.    o   MUST, SHALL, or MANDATORY -- the item is an absolute requirement
  71.        of the specification.
  72.  
  73.    o   SHOULD or RECOMMEND -- this item should generally be followed for
  74.        all but exceptional circumstances.
  75.  
  76.    o   MAY or OPTIONAL -- the item is truly optional and may be followed
  77.        or ignored according to the needs of the implementor.
  78.  
  79. 5.  Introduction
  80.  
  81.    The goal of this specification is to allow compatible and
  82.    interoperable implementations for transmitting IP datagrams, ARP and
  83.    InARP requests and replies over ATM Adaptation Layer 5 (AAL5)[6].
  84.  
  85.    Initial deployment of ATM provides a LAN segment replacement for
  86.    ethernet networks and as wire-replacement for dedicated public
  87.    telecommunication lines between IP routers. In the former model,
  88.    local IP routers with one or more ATM interfaces will connect islands
  89.    of local ATM networks. ATM-FORUM compliant addressing will be used
  90.    within these local ATM networks. In the latter model, public ATM
  91.    networks will be used to connect IP routers, which in turn may or may
  92.    not connect to local ATM networks. Public networks will use ITU-TSS
  93.    and ANSI standards for addressing in ATM.
  94.  
  95.    The characteristics and features of ATM networks are different than
  96.    those found in LAN's:
  97.  
  98.    o   ATM provides a virtual circuit switched environment. VC setup may
  99.        be done on either a Permanent Virtual Circuit (PVC) or dynamic
  100.        Switched Virtual Circuit (SVC) basis. SVC call management
  101.        signalling is performed via Q.93B implementations [7,9].
  102.  
  103.    o   Data to be passed by a VC is segmented into 53 octet quantities
  104.        called cells (5 octets of ATM header and 48 octets of data).
  105.  
  106.    o   ATM standards provide several formats for the exchange of
  107.        Protocol Data Units (PDU's), these formats are called ATM
  108.  
  109.  
  110.  
  111. Laubach                                                         [Page 2]
  112.  
  113. DRAFT                Classical IP and ARP over ATM           August 1993
  114.  
  115.  
  116.        Adaptation Layers (AAL's). When a virtual circuit is created a
  117.        specific AAL type is associated with the VC.  This type is
  118.        specified either by administrative control for PVC's or via
  119.        signalling for SVC's. There are five different AAL format types,
  120.        which are commonly referred to as "AALn", where "n" is a number
  121.        from one 1 through 5.  There is no field in an ATM cell header
  122.        which carries this AAL type value, rather it is known at each hop
  123.        of the path due to the call setup mechanism. The AAL5 format
  124.        specifies a packet format with a maximum size of 64K - 8 user
  125.        data octets. Cells for an AAL5 PDU are transmitted first to last,
  126.        the last cell indicating end of PDU. ATM standards guarantee that
  127.        on a given VC, cell ordering is preserved end-to-end.
  128.  
  129.    o   ATM-FORUM signalling defines point-to-point and point-to-
  130.        multipoint circuit setup [9].  Multipoint-to-multipoint virtual
  131.        circuits are not not yet a conformance requirement of the ATM-
  132.        FORUM.
  133.  
  134.    o   ATM-FORUM local LAN addresses (in the address resolution protocol
  135.        context) use the same basic format as GOSIP NSAP's [11].  Note:
  136.        ATM-FORUM addresses should not be construed at being GOSIP
  137.        NSAP's, they are not, the administration is different, which
  138.        fields get filled out are different, etc.
  139.  
  140.    This memo describes the initial deployment of ATM within "classical"
  141.    IP networks as a direct replacement for local area networks
  142.    (ethernets) and for IP links which interconnect routers, either
  143.    within or between administrative domains. The "classical" model here
  144.    refers to the treatment of the ATM host adapter as a networking
  145.    interface to the IP protocol stack.
  146.  
  147.    Characteristics of the classical model are:
  148.  
  149.     o  One default maximum MTU size for the network interface,
  150.        consistent with current implementations.
  151.  
  152.     o  Default LLC/SNAP encapsulation of IP packets.
  153.  
  154.     o  IP destinations map to VC's via ARP and end-to-end IP routing
  155.        stays the same, consistent with current model.
  156.  
  157.     o  ARP's stay within the LIS, current ARP architecture stays the
  158.        same.
  159.  
  160.     o  One IP subnet is used for many hosts and routers. A separate VC
  161.        is used for each station-to-station pair, one subnet is used for
  162.        all these VC's.
  163.  
  164.  
  165.  
  166.  
  167. Laubach                                                         [Page 3]
  168.  
  169. DRAFT                Classical IP and ARP over ATM           August 1993
  170.  
  171.  
  172.    The "global" ATM model is an evolution of the classical model where
  173.    the ATM network becomes more fully deployed and globally available.
  174.    In this model, the traditional protocol stack architecture also
  175.    evolves allowing applications to map directly on VC's (e.g., TCP and
  176.    UDP ports map directly onto VC's) and ARP mechanisms are no longer
  177.    bound to LIS boundaries as queries and replies may go global.  IP
  178.    will evolve to take advantage of the network services provided by the
  179.    global ATM network.
  180.  
  181.    Characteristics of the global model are:
  182.  
  183.     o  MTU size is negotiated per VC via ATM signalling, requires MTU
  184.        size be separated from interface in protocol stack.
  185.  
  186.     o  IP encapsulation is negotiated per VC via ATM signalling,
  187.        requires common signalling to be implemented and globally
  188.        available.
  189.  
  190.     o  Applications map directly to VC's, requiring changes to
  191.        TCP/UDP/IP to allow ports to map directly on to VC's
  192.  
  193.     o  ARP's are global, ARP architecture needs to change to support a
  194.        robust global client/server model.
  195.  
  196.     o  Differing quality of service (QOS) guarantees will exist on a per
  197.        application and per VC basis.
  198.  
  199.    The deployment of ATM into the Internet community is just beginning
  200.    and will take many years to complete. During the early part of this
  201.    period, we expect deployment to follow traditional IP subnet
  202.    boundaries for the following reasons:
  203.  
  204.     o  Administrators and managers of IP subnetworks will tend to
  205.        initially follow the same models as they currently have deployed.
  206.        The mindset of the community will change slowly over time as ATM
  207.        increases its coverage and builds its credibility.
  208.  
  209.     o  Policy administration practices rely on the security, access,
  210.        routing, and filtering capability of IP Internet gateways: i.e.
  211.        firewalls. ATM will not be allowed to "back-door" these
  212.        mechanisms until ATM provides better management capability than
  213.        the existing services and practices.
  214.  
  215.     o  Standards for global IP over ATM will take some time to complete
  216.        and deploy.
  217.  
  218.    This memo details the treatment of the classical model of IP and ARP
  219.    over ATM. There are those would like to have IP-over-ATM begin by
  220.  
  221.  
  222.  
  223. Laubach                                                         [Page 4]
  224.  
  225. DRAFT                Classical IP and ARP over ATM           August 1993
  226.  
  227.  
  228.    breaking the classical model - this memo represents the view that we
  229.    must walk before we can run. This memo does not preclude the
  230.    subsequent evolution of ATM networks as they become more globally
  231.    deployed and interconnected and the evolution of TCP and IP to take
  232.    advantage of these changes - these will be the subject of future
  233.    documents. This memo does not address issues related to transparent
  234.    data link layer interoperability.
  235.  
  236. 6.  IP Subnetwork Configuration
  237.  
  238.    In the LIS scenario, each separate administrative entity configures
  239.    its hosts and routers within a closed logical IP subnetwork. Each LIS
  240.    operates and communicates independently of other LIS's over the same
  241.    ATM network. Hosts connected to ATM communicate directly to other
  242.    hosts within the same LIS. Communication to hosts outside of the
  243.    local LIS is provided via an IP router. This router is a station
  244.    attached to the ATM network that is configured as a member of two or
  245.    more LIS's. This configuration may result in a number of disjoint
  246.    LIS's operating over the same ATM network. Hosts of differing IP
  247.    subnets would communicate via an intermediate router even though a
  248.    direct virtual circuit between the two hosts may be available over
  249.    the ATM network.
  250.  
  251.    The requirements for IP member stations (hosts, routers) operating in
  252.    an ATM LIS configuration are:
  253.  
  254.    o   All members have the same IP network/subnet number.
  255.  
  256.    o   All stations within an LIS are accessed directly over the ATM
  257.        network.
  258.  
  259.    o   All stations outside of the LIS are accessed via a router.
  260.  
  261.    o   All members of an LIS must have a mechanism for resolving IP
  262.        addresses to ATM addresses via ARP [4] when using SVC's.
  263.  
  264.    o   All members within a LIS MUST be able to communicate with all
  265.        other members in the same LIS; i.e., the topology is fully
  266.        meshed. There should be no administrative restrictions at the ATM
  267.        level that prevent VC's from operating between all pairs of
  268.        stations.
  269.  
  270.    The following list identifies a set of ATM specific parameters that
  271.    MUST be implemented in each IP station connected to the ATM network.
  272.    The parameter values MUST be user configurable:
  273.  
  274.    o   ATM Hardware Address (atm$ha). The ATM address of the individual
  275.        IP station. Each host must be configured to accept datagrams
  276.  
  277.  
  278.  
  279. Laubach                                                         [Page 5]
  280.  
  281. DRAFT                Classical IP and ARP over ATM           August 1993
  282.  
  283.  
  284.        destined for this address
  285.  
  286.    o   ATM ARP Request Address (atm$arp-req). atm$arp-req is the ATM
  287.        hardware address of an individual ARP server located within the
  288.        LIS to which ARP requests are to be sent for the resolution of
  289.        target protocol addresses to target hardware addresses for SVC
  290.        connections. That server must have authoritative responsibility
  291.        for resolving ARP requests of all IP stations within the LIS.
  292.  
  293.    It is RECOMMENDED that routers providing LIS functionality over the
  294.    ATM network also support the ability to interconnect differing LIS's.
  295.    Routers that wish to provide interconnection of differing LIS's MUST
  296.    be able to support multiple sets of these parameters (one set for
  297.    each connected LIS) and be able to associate each set of parameters
  298.    with a specific IP network/ subnet number. In addition, it is
  299.    RECOMMENDED that a router be able to provide this multiple LIS
  300.    support with a single physical ATM interface that may have one or
  301.    more individual ATM addresses.
  302.  
  303. 7.  Packet Format
  304.  
  305.    Implementations MUST support IEEE 802.2 LLC/SNAP encapsulation as
  306.    described in [2].  LLC/SNAP encapsulation is the default packet
  307.    format for IP datagrams.
  308.  
  309.    This memo recognizes that other encapsulation methods may be used
  310.    however, in the absence of other knowledge or agreement, LLC/SNAP
  311.    encapsulation is the default.
  312.  
  313.    This memo recognizes the future development of end-to-end signalling
  314.    within ATM that will allow negotiation of encapsulation method on a
  315.    per-VC basis.  Signalling negotiations are beyond the scope of this
  316.    memo.
  317.  
  318. 8.  MTU Size
  319.  
  320.    The default MTU size for IP stations operating over the ATM network
  321.    SHALL be 9180 octets. The LLC/SNAP header is 8 octets, therefore the
  322.    default ATM AAL5 protocol data unit size is 9188 octets. In classical
  323.    IP subnets, values other than the default can only be used if and
  324.    only if all stations in the LIS have been configured to use the non-
  325.    default value.
  326.  
  327.    This memo recognizes the future development of end-to-end signalling
  328.    within ATM that will allow negotiation of MTU size on a per-VC basis.
  329.    Signalling negotiations are beyond the scope of this document.
  330.  
  331. 9.  ADDRESS RESOLUTION
  332.  
  333.  
  334.  
  335. Laubach                                                         [Page 6]
  336.  
  337. DRAFT                Classical IP and ARP over ATM           August 1993
  338.  
  339.  
  340.    Address resolution within an ATM logical IP subnet shall make use of
  341.    the Address Resolution Protocol (ARP) [3] and the Inverse Address
  342.    Resolution Protocol (InARP) [9] and all IP stations are required to
  343.    support these protocols.  Use of these protocols differ depending on
  344.    whether permanent virtual circuits (PVC's) or switched virtual
  345.    circuits (SVC's) are used.
  346.  
  347.    Permanent Virtual Circuits
  348.  
  349.    An IP station must have a mechanism for determining what PVC's it
  350.    has, and in particular which PVC's are being used for LLC/SNAP
  351.    encapsulated protocols.  The details of the mechanism are beyond the
  352.    scope of this memo.
  353.  
  354.    All IP stations supporting permanent virtual circuits are required to
  355.    use the Inverse Address Resolution Protocol (InARP) as defined in [9]
  356.    on those virtual circuits using LLC/SNAP encapsulation. In a strict
  357.    PVC environment, the receiver shall infer the relevant virtual
  358.    circuit from the virtual circuit on which the InARP request
  359.    (InARP_REQUEST) or response (InARP_REPLY) was received. When the ATM
  360.    source and/or target hardware address is unknown, the corresponding
  361.    hardware address length in the InARP packet must be set to zero (0)
  362.    indicating a null length, otherwise the appropriate address field
  363.    should be filled in and the corresponding length set appropriately.
  364.    InARP packet format details are presented later in this memo.
  365.  
  366.    From [9]: "When the requesting station receives the InARP reply, it
  367.    may complete the ARP table entry and use the provided address
  368.    information.  Note: as with ARP, information learned via InARP may be
  369.    aged or invalidated under certain circumstances."  It is the
  370.    responsibility of each IP station supporting ATM permanent virtual
  371.    circuits to re-validate ARP table entries as part of the aging
  372.    process.  See the section below on "ARP Table Aging - All Stations".
  373.  
  374.    Switched Virtual Circuits
  375.  
  376.    ATM switched virtual circuits require support for ARP in the non-
  377.    broadcast, non-multicast environment that ATM networks currently
  378.    provide. To meet this need a single ARP server will be located within
  379.    the LIS. This server must have authoritative responsibility for
  380.    resolving the ARP requests of all IP stations within the LIS.
  381.  
  382.    The server itself is inherently passive in that it depends on the
  383.    clients in the LIS to initiate the ARP registration procedure. An
  384.    individual client connects to the ARP server using a point-to-point
  385.    virtual circuit. The server, upon receiving a new virtual circuit
  386.    specifying LLC/SNAP encapsulation, will initiate an InARP request to
  387.    determine the IP address of the client. The InARP reply from the
  388.  
  389.  
  390.  
  391. Laubach                                                         [Page 7]
  392.  
  393. DRAFT                Classical IP and ARP over ATM           August 1993
  394.  
  395.  
  396.    client contains the information necessary for the ARP server to build
  397.    its ARP table cache. This information is used to generate replies to
  398.    the ARP requests it receives.
  399.  
  400.    The ARP server mechanism requires that each client be
  401.    administratively configured with the ATM hardware address of the ARP
  402.    server atm$arp-req as defined earlier in this memo. There is to be
  403.    one and only one ARP server operational per logical IP subnet. This
  404.    ARP server must be administratively configured so that it knows it is
  405.    the ARP server.  The ARP server MUST be configured with an IP address
  406.    for each logical IP subnet it is serving to support InARP requests.
  407.  
  408.    This memo recognizes that a single ARP Server is not as robust as
  409.    multiple servers which synchronize their databases correctly. This
  410.    document is defining the client-server interaction by using a simple,
  411.    single server approach as a reference model, and does not prohibit
  412.    more robust approaches which use the same client-server interface.
  413.  
  414.    ARP Server Operational Requirements
  415.  
  416.    The ARP server accepts switched virtual circuit connections from
  417.    other ATM stations. At call setup and if the VC supports LLC/SNAP
  418.    encapsulation, the ARP server will transmit to the originating ATM
  419.    station an InARP request (InARP_REQUEST) for each logical IP subnet
  420.    the server is configured to serve. After receiving an InARP reply
  421.    (InARP_REPLY), the server will examine the IP address and the ATM
  422.    hardware address. The server will add (or update) the <hardware
  423.    address, IP address> map entry and timestamp into its ARP table.  If
  424.    the InARP IP address duplicates a table entry IP address and the
  425.    InARP hardware address does not match the table entry hardware
  426.    address and there is an open virtual circuit associated with that
  427.    table entry, the InARP information is discarded and no modifications
  428.    to the table are made. ARP table entries persist until aged or
  429.    invalidated.  VC call tear down does not remove ARP table entries.
  430.  
  431.    The ARP server, upon receiving an ARP request (ARP_REQUEST), will
  432.    generate the corresponding ARP reply (ARP_REPLY) if it has an entry
  433.    in its ARP table or a negative ARP reply (ARP_NAK).  The ARP_NAK
  434.    response is an extension to the ARP protocol and is used to improve
  435.    the robustness of the ARP server mechanism.  With ARP_NAK, a client
  436.    can determine the difference between a catastrophic server failure
  437.    and an ARP table lookup failure.  The ARP_NAK packet format is the
  438.    same as the received ARP_REQUEST packet format with the operation
  439.    code set to ARP_NAK, i.e., the ARP_REQUEST packet data is merely
  440.    copied for transmission with the ARP_REQUEST operation code reset to
  441.    ARP_NAK.
  442.  
  443.    ARP table information timeout update: when the server receives an ARP
  444.  
  445.  
  446.  
  447. Laubach                                                         [Page 8]
  448.  
  449. DRAFT                Classical IP and ARP over ATM           August 1993
  450.  
  451.  
  452.    request over a virtual circuit, and the source information (IP and
  453.    hardware address) match the association already in the ARP table, and
  454.    the hardware address matches that associated with the virtual circuit
  455.    (in the SVC environment), then the server may update the timeout on
  456.    the ARP table entry.
  457.  
  458.    ARP Client Operational Requirements
  459.  
  460.    The ARP client is responsible for contacting the ARP server to
  461.    register its own ARP information and to gain and refresh ARP
  462.    information about other IP stations.  ARP clients are required to:
  463.  
  464.    1. Initiate the virtual circuit connection to the ARP server for
  465.    transmitting and receiving ARP and InARP packets.
  466.  
  467.    2. Respond to ARP_REQUEST and InARP_REQUEST packets received on any
  468.    VC appropriately.
  469.  
  470.    3. Generate and transmit ARP_REQUEST packets to the ARP server and to
  471.    process ARP_REPLY and ARP_NAK packets from the server appropriately.
  472.    ARP_REPLY packets should be used to build/refresh ARP table entries.
  473.  
  474.    4. Generate and transmit InARP_REQUEST packets as needed and to
  475.    process InARP_REPLY packets appropriately.  InARP_REPLY packets
  476.    should be used to build/refresh ARP table entries.
  477.  
  478.    5. Provide an ARP table aging function to remove old ARP tables
  479.    entries after a convenient period of time.
  480.  
  481.    Note: if the client does not maintain an open VC to the server, the
  482.    client must refresh its ARP information with the server at least once
  483.    every 20 minutes.  This is done by opening a VC to the server and
  484.    exchanging the initial InARP packets.
  485.  
  486.    ARP Table Aging - All stations
  487.  
  488.    A client or server must have knowledge of any open VC's it has
  489.    (permanent or switched), their association with an ARP table entry,
  490.    and in particular, which VC's support LLC/SNAP encapsulation.
  491.  
  492.    Client ARP table entries are valid for a maximum time of 15 minutes.
  493.  
  494.    Server ARP table entries are valid for a minimum time of 20 minutes.
  495.  
  496.    Prior to aging (removing) an ARP table entry, all stations must
  497.    generate an InARP_REQUEST on any open VC associated with that entry.
  498.    If an InARP_REPLY is received, that table entry is updated and not
  499.    deleted.  If there is no open VC associated with the table entry, the
  500.  
  501.  
  502.  
  503. Laubach                                                         [Page 9]
  504.  
  505. DRAFT                Classical IP and ARP over ATM           August 1993
  506.  
  507.  
  508.    entry is deleted.
  509.  
  510.    ARP and InARP Packet Format
  511.  
  512.    Internet addresses are assigned independent of ATM-FORUM NSAP
  513.    addresses. Each host implementation MUST know its own internet and
  514.    ATM address(es) and respond to address resolution requests
  515.    appropriately.  Hosts MUST also use ARP to map Internet addresses to
  516.    ATM hardware addresses when needed.
  517.  
  518.    The ARP and InARP protocol has several fields that have the following
  519.    format and values:
  520.  
  521.    Data:
  522.      ar$hrd     16 bits  Hardware type
  523.      ar$pro     16 bits  Protocol type
  524.      ar$shln     8 bits  Octet length of source hardware address (m)
  525.      ar$spln     8 bits  Octet length of source protocol address (n)
  526.      ar$op      16 bits  Operation code (request or reply)
  527.      ar$thln     8 bits  Octet length of target hardware address (p)
  528.      ar$tpln     8 bits  Octet length of target protocol address (q)
  529.      ar$sha     moctets  source hardware address
  530.      ar$spa     noctets  source protocol address
  531.      ar$tha     poctets  target hardware address
  532.      ar$tpa     qoctets  target protocol address
  533.  
  534.     Where:
  535.  
  536.      ar$hrd  -  assigned to ATM-FORUM NSAP address family and is
  537.                 dd decimal (0x00nn) [4].
  538.  
  539.      ar$pro  -  see Assigned Numbers for protocol type number for
  540.                 the protocol using ARP. (IP is 0x0800).
  541.  
  542.      ar$shln -  length of the source hardware NSAP address length.
  543.  
  544.      ar$spln -  length in bytes of the source protocol address. For
  545.                 IP ar$spln is 4.
  546.  
  547.      ar$op   -  The operation type value (decimal):
  548.                 ARP_REQUEST   = 1
  549.                 ARP_REPLY     = 2
  550.                 InARP_REQUEST = 8
  551.                 InARP_REPLY   = 9
  552.                 ARP_NAK       = ??
  553.  
  554.      ar$thln -  length of the target hardware NSAP address length.
  555.  
  556.  
  557.  
  558.  
  559. Laubach                                                        [Page 10]
  560.  
  561. DRAFT                Classical IP and ARP over ATM           August 1993
  562.  
  563.  
  564.      ar$tpln -  length in bytes of the target protocol address. For
  565.                 IP ar$tpln is 4.
  566.  
  567.      ar$sha  -  source NSAP address.
  568.  
  569.      ar$spa  -  source protocol address.
  570.  
  571.      ar$tha  -  target NSAP address.
  572.  
  573.      ar$tpa  -  target protocol address.
  574.  
  575.    The ATM hardware addresses in ARP packets (ar$sha, ar$tha) SHALL be
  576.    ATM-FORUM specified NSAP addresses [9].
  577.  
  578.    The same NSAP encoding SHALL be used within an LIS and replies will
  579.    use the same encoding as queries. For example, NSAP's may encode IEEE
  580.    48-bit MAC addresses or may encode E.164 addresses. Within the LIS
  581.    either IEEE MAC or E.164 hardware addresses may be used but not both.
  582.  
  583.    ARP packets are to be encoded in AAL5 PDU's using LLC/SNAP
  584.    encapsulation. The format of the AAL5 CPCS-SDU payload field for
  585.    routed non-ISO PDU's is:
  586.  
  587.                Payload Format for Routed non-ISO PDU's
  588.                +------------------------------+
  589.                |        LLC 0xAA-AA-03        |
  590.                +------------------------------+
  591.                |        OUI 0x00-00-00        |
  592.                +------------------------------+
  593.                |     Ethertype 0x08-06        |
  594.                +------------------------------+
  595.                |                              |
  596.                |         ARP Packet           |
  597.                |                              |
  598.                +------------------------------+
  599.  
  600.    The LLC value of 0xAA-AA-03 (3 octets) indicates the presence of a
  601.    SNAP header.
  602.  
  603.    The OUI value of 0x00-00-00 (3 octets) indicates that the following
  604.    two-bytes is an ethertype.
  605.  
  606.    The Ethertype value of 0x08-06 (2 octets) indicates ARP [4].
  607.  
  608.    The total size of the LLC/SNAP header is fixed at 8-octets. This
  609.    aligns the start of the ARP packet on a 64-bit boundary relative to
  610.    the start of the AAL5 SDU.
  611.  
  612.  
  613.  
  614.  
  615. Laubach                                                        [Page 11]
  616.  
  617. DRAFT                Classical IP and ARP over ATM           August 1993
  618.  
  619.  
  620.    The LLC/SNAP encapsulation for ARP presented here is consistent with
  621.    the treatment of multiprotocol encapsulation of IP over ATM AAL5 as
  622.    specified in [2] and in the format of ARP over IEEE 802 networks as
  623.    specified in [5].
  624.  
  625.    Traditionally, ARP requests are broadcast to all directly connected
  626.    IP stations within a LIS. It is conceivable in the future that larger
  627.    scaled ATM networks may handle ARP requests to destinations outside
  628.    the originating LIS, perhaps even globally; issues raised by ARP'ing
  629.    outside the LIS or by a global ARP mechanism are beyond the scope of
  630.    this memo.
  631.  
  632. 10.  IP Broadcast Address
  633.  
  634.    ATM does not support broadcast addressing, therefore there are no
  635.    mappings available from IP broadcast addresses to ATM broadcast
  636.    services. Note: this lack of mapping does not restrict stations from
  637.    transmitting or receiving IP datagrams specifying any of the four
  638.    standard IP broadcast address forms as described in [8].  Stations,
  639.    upon receiving an IP broadcast or IP subnet broadcast for their LIS,
  640.    must process the packet as if addressed to that station.
  641.  
  642. 11.  IP Multicast Address
  643.  
  644.    ATM does not support multicast address services, therefore there are
  645.    no mappings available from IP multicast addresses to ATM multicast
  646.    services.  Current IP multicast implementations (i.e., MBONE and IP
  647.    tunneling, see [10]) will continue to operate over ATM based logical
  648.    IP subnets if operated in the WAN configuration.
  649.  
  650.    This memo recognizes the future development of ATM multicast service
  651.    addressing by the ATM-FORUM. When available and widely implemented,
  652.    the roll-over from the current IP multicast architecture to this new
  653.    ATM architecture will be straightforward.
  654.  
  655. 12.  Security
  656.  
  657.    Security issues are not discussed in this memo.
  658.  
  659.    This memo recognizes the future development of ATM and IP facilities
  660.    for authenticated call setup, authenticated end-to-end application
  661.    knowledge, and data encryption as being required services for
  662.    globally connected ATM networks. These future security facilities and
  663.    their use by IP networks are beyond the scope of this memo.
  664.  
  665. 13.  Open Issues
  666.  
  667.    o   A proposal was put before the Internet Assigned Numbers Authority
  668.  
  669.  
  670.  
  671. Laubach                                                        [Page 12]
  672.  
  673. DRAFT                Classical IP and ARP over ATM           August 1993
  674.  
  675.  
  676.        to approve a request to create an ARP hardware type of "ATM-FORUM
  677.        NSAP address".  IANA has not responded as of this date.
  678.  
  679.    o   Well known ATM hardware address(es) for ARP servers?  It would be
  680.        very handy if we came up with a set of well known ATM addresses
  681.        for ARP services.  We should probably have well-known PVC numbers
  682.        for a non-SVC environment also.
  683.  
  684.    o   Interim Local Management Interface (ILMI) services will not be
  685.        generally implemented by some providers and vendors and will not
  686.        be used to obtain the ATM address network prefix from the network
  687.        [9].  Meta-signalling does provide some of this functionality and
  688.        in the future we need to document the options.
  689.  
  690. REFERENCES
  691.  
  692.    [1] Piscitello, D., and Lawrence, J., "IP and ARP over the SMDS
  693.        Service", RFC1209, USC/Information Sciences Institute, March
  694.        1991.
  695.  
  696.    [2] Heinanen, Juha, "Multiprotocol Encapsulation over ATM Adaptation
  697.        Layer 5", RFC1483, USC/Information Sciences Institute, July 1993.
  698.  
  699.    [3] Plummer, D., "An Ethernet Address Resolution Protocol - or -
  700.        Converting Network Addresses to 48.bit Ethernet Address for
  701.        Transmission on Ethernet Hardware", RFC 826, MIT, November 1982.
  702.  
  703.    [4] Reynolds, J., and Postel, J., "Assigned Numbers", RFC1340, USC/
  704.        Information Sciences Institute, July 1992.
  705.  
  706.    [5] Postel, J., and Reynolds, J., "A Standard for the Transmission of
  707.        IP Datagrams over IEEE 802 Networks", RFC1042, USC/Information
  708.        Sciences Institute, February 1988.
  709.  
  710.    [6] CCITT, "Draft Recommendation I.363", CCITT Study Group XVIII,
  711.        Geneva, 19-29 January 1993.
  712.  
  713.    [7] CCITT, "Draft text for Q.93B", CCITT Study Group XI, 23 September
  714.        - 2 October 1992.
  715.  
  716.    [8] Braden, R., "Requirements for Internet Hosts -- Communication
  717.        Layers", RFC1122, USC/Information Sciences Institute, October
  718.        1989.
  719.  
  720.    [9] ATM-FORUM, "ATM User-Network Interface Specification Version 3.0.
  721.        (DRAFT)", ATM-FORUM, 480 San Antonio Road, Suite 100, Mountain
  722.        View, CA 94040, June 1993.
  723.  
  724.  
  725.  
  726.  
  727. Laubach                                                        [Page 13]
  728.  
  729. DRAFT                Classical IP and ARP over ATM           August 1993
  730.  
  731.  
  732.    [10] Deering, S, "Host Extensions for IP Multicasting", RFC1112,
  733.        USC/Information Sciences Institute, August 1989.
  734.  
  735.    [11] Colella, Richard, and Gardner, Ella, and Callon, Ross,
  736.        "Guidelines for OSI NSAP Allocation in the Internet", RFC1237,
  737.        USC/Information Sciences Institute, July 1991.
  738.  
  739. Author's Address
  740.  
  741.    Mark Laubach
  742.    Hewlett-Packard Laboratories
  743.    1501 Page Mill Road
  744.    Palo Alto, CA 94304
  745.  
  746.    Phone: 415.857.3513
  747.    FAX:   415.857.8526
  748.    EMail: laubach@hpl.hp.com
  749.  
  750.  
  751.  
  752.  
  753.  
  754.  
  755.  
  756.  
  757.  
  758.  
  759.  
  760.  
  761.  
  762.  
  763.  
  764.  
  765.  
  766.  
  767.  
  768.  
  769.  
  770.  
  771.  
  772.  
  773.  
  774.  
  775.  
  776.  
  777.  
  778.  
  779.  
  780.  
  781.  
  782.  
  783. Laubach                                                        [Page 14]
  784.  
  785.